Torrelus Toh'Kon
Cadre Assault Force
This is why we cant have nice things
4
   |
Posted - 2013.01.18 11:49:00 -
[1] - Quote
Taking CSM Two step's blog post as a starting point, I'd like to highlight one specific line right near the top, from the CSM minutes - "It would, however, only affect the group of people who manage POSes."
I am sorry CCP, but you have here revealed two MAJOR flaws in your collective thinking.
1) You have seriously under estimated how many people care about modular POS, or POS control/maintenance/access/etc. So called "POS managers" exist ONLY because the existed implementation is both geared towards that point of view, and enforces it by being unbearable to the masses.
2) You have seriously under estimated just how much you can change POSs, in terms of player interaction (HCI, believe it or not you 'could' even make them noob 'friendly'), software level design and implementation, and let's not forget fundamental behaviour and functionality.
Yes, POSs have a huge number of things tied into them. For start, hangers and ship array for living, refineries, labs, reactions, construction arrays, defensive mods, and optionally manable offensive mods. For another list, indy corp science work, drug manufacture, super capital manufacture, jump bridges, moon goo, any and all parts of wormhole life (how many people do that, insignificant minority, all POS managers you say?), oh and lets not forget the role they used to have in sov control. I dare suggest more could be listed.
I agree with CCP, this is a huge complicated and seriously daunting task. I would not have suggested doing it in a 'single' expansion under the old system, but also find it inconceivable that sections cannot (or would not, or might not) be linked to the themes of the next three or four expansions.
You want themes, I have one. It ties in to problems with POSs and null-sec. I call it "helping the little guy", or "how small entities can live in null-sec without an outpost or clone station". Oh yeah BTW, null-sec has a serious issue with distribution of medical clone facilities. Imagine being able to build a POS up to be a bit like an outpost on a smaller scale. This means lots of personal hanger space (anchor for self, access by allowance list as in custom channels), the ability to boost the shield/fitting stats of a tower (either linking of towers, or new modules for shield/PG/CPU), and finally addition of a new POS module for medical clones (corp has automatic 'office' rites for medical). Dedicated fuel hangers (s/m/l) would solve scaling better than internal bays, and time (seconds) taken to consume a block instead of number of blocks per unit time.
On the inevitable thought of "but that'll mean far too much new artwork", feel free to reuse existing models where appropriate for a year or so. There in no reason why a 'modular personal hanger' should look any different from the old fashioned 'generic achored hanger' at first release. Much as we love Eve being pretty, we prefer function before form. You don't even need to replace the anchoring with a nicer Lego(tm) clip-on functionality until the last stage two years from now.
Now I return to where I started on this, with the one line quote and the flaws it reveals. I offer you my professional opinions and advice as a software engineer with experience creating complicated modular systems on multi-year projects.
1) DO NOT ever start a system rebuild be asking things like "what's wrong with the current system" and assuming things like "few users means few potential users". Equally, never start by looking to 'fix' or 'improve' the current system. Generally speaking, looking at an old system will not help, because the old system doesn't work. Invariably it either never worked, or the use case out grew the solution.
2) Always start with a fresh slate, ask "what is possible, desirable, desperately wanted, and needed" (ask in that order, implement in reverse). Ask repeatedly in different contexts, "what might different classes of user do with it, back-end admin (databases/etc), technical freedom versus limitation, etc".
3) Just because you're 'Agile' doesn't mean you can't be predetermined. Do the long term final design up front, and be certain it's one you can stick with. Do it at the high level, and do it at the mid level, let Agile handle the low level. It's easy to define a large 'complex' system that can be compartmentally built and work flawlessly, if you ask enough questions; oh and if you build the answers of "I don't know (yet)" into the design. In so doing, develop a 'general' solution instead of a custom one. You have recently succeeded at this sort of thing with smaller issues, such as Crimewatch. In fact as you demostrated in Crimewatch, no software problem is too complicated if you ask simple enough questions.
Please, please, please CCP, make 'POSs for all' and 'null-sec for the little guy' your top priorities for summer 2013. We will forgive you a small implementation, if you have instead a solid and guarunteed design for these features that will be incrementally delivered, without failure or back tracking.
P.S. Not only does null-sec lack sufficient medical facilites, but sov space is impossible for the little folk. It's giants and pets. Perhaps sov maintenance bills should increase exponentially with the number and quality of systems held. |